技术讨论 | XCM 的实际使用场景探讨

加入 PolkaWorld 社区，共建 Web 3.0！

本文是 Polkadot 论坛中关于 XCM/XCMP 合适的使用场景的讨论。这个帖子原本于 2022 年 7 月 12 日发布于 Parity 内部论坛，后迁移到 Polkadot 公开论坛，并继续在波卡社区中公开进行对话。

Shawn Tabrizi：

在剑桥 Polkadot 区块链学院的一次对话中，我想清楚了应该如何描述 XCMP/Polkadot 的有效使用方式，从而避免生态中其他人对它的误解。

我当然不是所有方面的专家，所以也许其中一些看法是错误的，很想听听看 Rob 和 Gavin 的意见。

Polkadot 想做的很简单：

• 让交易在多条区块链中并行处理从而实现扩展（分片）

• 让这些多条区块链针对特定使用场景进行专业化和优化从而实现扩展（异构）

然而，这些选择也是有代价的：

• 安全可靠地构建这些系统的技术成本和复杂性。主要是在 Polkadot 协议开发方面，大概这就是为什么它需要 5 年以上的时间来开发，而且还会继续投入。这一点是可以克服的。

• 跨区块链分片发送消息很慢。比大家已经习惯使用的 DeFi 和所有 “跨合约” 通信都要慢得多。这一点我认为是无法解决的问题。

在我看来，大家想用平行链复制多合约场景，但如果我们这样做，Polkadot 会做得很糟糕，因为 Polkadot（或其他链）根本无法做到这一点。这是物理上行不通的。

相反，Polkadot 打赌用户实际上不会在平行链之间频繁移动资产，在这个情况下，专业链的优势就值得了。

让我们想象两个 dApp：一个 DEX 和一个像 Tornado Cash 这样的隐私层。

• 假设以太坊上的 DEX 合约可以在 0.2 秒内执行 Swap。

• 而专用的 DEX 平行链可以在 0.1 秒内执行 Swap。

• 假设 Tornado Cash 合约可以在 1 秒内执行隐私操作。

• 而专用的隐私平行链可以在 0.5 秒内执行相同的操作。

注意：我认为这里已经巨大低估了平行链的速度。我认为有证据表明平行链比它们的合约对手快数百或数千倍。

现在我们假设在以太坊上，将 DEX 交换的 token 移动到隐私层基本上是零成本的。

在 Polkadot 上，我们应该预计两条平行链之间的 XCMP 传输至少需要 12 秒。

这意味着，如果我们想强调用户可以快速将一些 token 转移到 DEX，交换一些 token，然后将其移动到隐私层以隐藏他们的交易，然后返回到某个最终账户的场景，我们将如此远远落后于以太坊。

相反，突出 Polkadot 优势的场景是当你进行 10,000 次 DEX 交换，然后一次转移到隐私层以隐藏所有这些操作时。在这种情况下，你实际上会节省更多时间，因为这些 DEX 操作中的每一个都已在专用区块链上进行了优化，并且 XCMP 的成本被在更优化的环境中执行所节省的所有时间（和费用）所抵消。

这对于用户和产品将如何在 Polkadot 上构建意味着什么？

好吧，平行链实际上并不会那么专注，至少，它们大概率都会为 DEX（如果它们管理多个 token）、智能合约等常见操作提供 “足够好” 的解决方案（用于扩展其链上的功能） …

与主要产品相比，这些平行链会将这些应用作为次要功能。借助 Substrate 和我们的模块化 pallet 系统，他们可以非常简单地实现这些功能。向任何平行链添加 DEX 功能就像在其 Runtime 添加新 pallet 一样简单。

然而，这并不意味着 DEX 平行链的消亡，因为我们都知道像 DEX 这样的系统在高流动性、多种可用资产方面进行了优化，并且只有专门的 DEX 链才能将其作为主要特色来提供。如果你在某些情况下进行小规模 Swap，你可能不会太在意 DEX 交易是否优化程度最高，但如果你要进行大交易，你可能会想要降低成本，将资产转到一条在这方面更具竞争力的 DEX 平行链上。合约平行链也是如此。

这也意味着用户最终可能会在他们会用到的每条链上拥有数量 “够用” 的资产。用户一般不会每次想要在平行链上执行一项操作，就从波卡上转出 “刚刚好” 数量的 token，然后执行该操作。相反，他们可能会预测在未来很长一段时间内会多经常用到另一条平行链，将足够的资产转移到该链以处理所有这些操作（以及更多），并在该平行链上管理这些余额。

这意味着我们可能应该指导团队构建更少的跨多个平行链执行操作的 UI，而是专注于为单个平行链上的所有操作提供专用 UI，以及用于管理跨多链资产的真正好用的 UI，然后去做一次性的转账。

这是否意味着 XCM 的所有可编程性都是无用的？不，因为 XCM 还针对合约，所有这些跨合约调用都是免费的（我们最初的假设），但很可能 XCMP 和跨平行链可编程性会很少，因为你可以在 XCMP 操作的任何一方采取的 “action” 数量不会那么大，因此并没有真正超过转账本身的高成本。

如果我们沿着这个思路继续思考，我们可能会更加理解一些行为，以及了解什么场景在 Polkadot 上能真正成功。

我有什么理解错了的地方吗？

如果我的理解是对的，我们的目标是否会有所改变？

Gavin：

我觉得平行链聚焦并定义边界点的不是 “应用”，而是应用类型（也可能被称为 “链上行业”），以及随之而来的用户和社区。

所以并不会是一条平行链用于隐私，一条平行链用于 DEX，而是会有几条用于 DeFi 的平行链，每条都有自己的边际优势（例如地区、社区、功能、稳定性和创新性之间的取舍……）。

santi：

这确实是个非常有趣的讨论。互操作性一直是我们宣传 Polkadot 的一个关键方面，理解这真正意味着什么确实很重要。

我可以看到 DEX 如何作为二级产品存在于多个平行链中（甚至用户都不知道它的存在），尽管我想知道是否可能存在一些潜在的流动性问题。甚至 DeFi 项目如何聚焦一个或另一个方面，但最终却会提供类似的产品。

但是，可能还有其他垂直领域可以带来适用于所有这些项目的解决方案，并且通过与其他平行链组合来真正带来价值。如果不是通过与生态中的其他平行链进行大量互操作，那么一条身份平行链将如何工作？实际上，我可以想象我不仅想要一个经过验证的身份，或者我需要同时验证多个身份，而是我想要一个经过验证的身份，好在生态中的其他地方做一些事。例如，专门做贷款的平行链可能会告诉他们的用户，如果他们验证自己的身份，就可以获得额外的好处。在我看来，文件存储平行链也是如此。某条文件存储平行链能否作为生态系统中的基础服务，其他平行链使用它并采取行动来保存、编辑、更改所有权，或者对某些元数据进行其他操作？这些可能是功能胜过速度并且可以区别对待的示例。这些链有可能成为公共利益链吗？

natalie：

我目前的想法（但很高兴受到挑战）是这些权衡

a）并不算太糟糕（可以通过多链应用程序的构建方式来缓解）

b）不会太出人意料，尤其是不仅谈论资产传送时（你说得对，我们在沟通中应该注意一点）

我认为其他链使用的功能越专业，用户就越愿意等待一会儿。DApp 将围绕这些限制构建，平衡用户体验（用户等待时间）和工作量（构建和维护 “足够好的版本” 的时间）。

类似于 Web2 中的集成。如果我想在新产品中使用信用卡付款，而 VisaSecure 弹出窗口需要几分钟，我会很乐意等待。用户并不沮丧，因为他们知道连接 Visa 进行 KYC、2FA、供应商/付款人验证、结算的整个过程很复杂（或者说我可以忍受，毕竟这个过程只发生一次）。如果我在应用中频繁转账，我会寄希望于其他解决方案，比如把我的卡进行预授权等。

好吧，平行链实际上并不会那么专注，至少，它们大概率都会为 DEX（如果它们管理多个 token）、智能合约等常见操作提供 “足够好” 的解决方案（用于扩展其链上的功能） …

→ 是的，我们很乐意多考虑一下链上产业。

这意味着我们可能应该指导团队构建更少的跨多个平行链执行操作的 UI，而是专注于为单个平行链上的所有操作提供专用 UI，以及用于管理跨多链资产的真正好用的 UI，然后去做一次性的转账。

→ 我不确定我们对平行链有多少指导，但向他们介绍并收集一些沿着这些思路的最佳实践听起来是合理的。

所以总而言之，我认为这与我们关于多链未来的故事并不矛盾。

希望我说清楚了，很高兴听到你的想法！

Shawn Tabrizi：

我觉得我们不应该真正直接指导团队，但由于这个建议听起来确实非常准确，我们可以和这些团队分享它，这样他们就可以自己考虑这些情况。

我认为让团队转变为将自己视为 “链上行业”，这对整体的叙事是有益的，并帮助团队真正了解如何在平台上构建成功的产品。

如果描述得足够清楚，也许可以将其复制到适当的平行链聊天中？或者我想我们可以做一个简短的介绍，并且制作一个视频？

Travis Kassab：

Natalie Till：首要的反馈是希望获得有关 XCM 使用场景的一些指导

是的，这些对话发生在平行链之间，分散在各个平行链的频道。我认为这很好，他们在自己寻找特定的协同作用。

一旦有了具体的使用场景，似乎平行链将越来越需要 Parity 的技术验证。例如 “在技术角度看这可行吗？是明智的吗？”

为了更加积极主动，Parity 可以汇总一系列原则：“XCM 的跨链设计注意事项”。

Shawn Tabrizi 通过比较多合约与跨链开启了这一讨论。或许还可以去总结一下区块链用户体验（例如，fanality 时间、费用、流动性、风险/安全性）并比较其他场景。

我确信这一切都可以从技术文档中表现出来，不过直白地写出来应该对平行链 PM 们有用。

对我来说，我见过的最好的 Web3 UX 是聚合器。放到你的 DEX 例子中的话，DEX 聚合器非常棒，因为它们触及了问题的核心：用户想要尽可能快、尽可能便宜（更少的费用、更少的滑点）的 token。用户并不关心具体哪个协议执行 Swap。

这意味着我们可能应该指导团队构建更少的跨多个平行链执行操作的 UI，而是专注于为单个平行链上的所有操作提供专用 UI，以及用于管理跨多链资产的真正好用的 UI，然后去做一次性的转账。

这可能是更长期的事情，但我认为我们应该围绕为链上行业服务的跨链聚合器构建 UI 进行对话。

你可以想象在 DeFi UI 中，会有一个跨链 DEX，它通过以下任一方式优化 fanality 时间、费用和滑点：

1. 使用平行链 DEX 进行本地 Swap

2. 将资产转到其他平行链，然后进行 Swap

3. 将资产连接到其他生态（例如以太坊），然后进行 Swap

虽然，我不认为平行链是为了构建这些聚合器而设计的，因为在某些情况下，它会将流动性从其链上抽走。尽管如此，我认为在后端使用多种协议，并模糊这种复杂性的聚合器将胜出。

Gavin：

我还是不能完全确定这些 “设计指南” 的意义是什么。跨链使用场景应该自然而然地出现，由团队看到提供的链上服务，并让自己的链上服务利用它来创建新的（复合的）服务而出现。

这通常可以在不以特别复杂的方式使用 XCM 的情况下完成 —— Transact 就是核心真正需要的一切。也就是说，我们可能有充分的理由希望改进 XCM，以提供更符合使用习惯的跨链语言来执行某些有用的操作（就像资产所有权控制的情况一样）。

在考虑 XCM 时要始终记住的要点是，它是一种主要围绕远程系统通信设计的语言（平行链/XCMP 是主要的预期使用场景）：它是异步的，不提供任何第一级的返回路径结果，本质上提供与 Transaction 相同的接口。Frame 中几乎没有语言支持作用于区块之间的结果（即期货/绿色线程），并且围绕 “传输层非即时” 的假设进行了优化。

这一切都意味着目前需要高度一致性的使用场景可能无法在 XCMP/XCM 中很好地工作。

Gavin：

在最基础的层面上，你可以将 XCM 视为允许一个区块链系统将交易发布到另一个区块链系统。这意味着它是区块链的设施，而不是用户。使用场景仅限于区块链团队/开发者，而不是广大公众。它的原型用例是允许区块链开发者让他们的链依赖于另一个链提供的服务，而不是部署一些类似的服务并相互竞争用户。其限制与在区块链上进行交易完全相同：存在延迟，它是单体的和异步的。

原文：https://forum.polkadot.network/t/how-xcm-will-actually-be-used-with-xcmp/190

翻译：PolkaWorld

• PolkaWorld Telegram 群：

  t.me/polkaworld

• PolkaWorld Youtube 频道：
  

  https://www.youtube.com/c/PolkaWorld

• PolkaWorld Twitter：

  @polkaworld_org

更多内容

关注 PolkaWorld

发现 Web 3.0 时代新机遇

点个 “在看” 再走吧！